1. Field of the Invention
Embodiments of the present invention generally relate to computer graphics and, more specifically, to the translation of a binary shader program for debugging a graphics application running on a remote device.
2. Description of the Related Art
The term rendering refers to a process performed by computer software and hardware in generates images that portray an object or scene. For example, a hand-held video game system may be configured to sequentially render frames of animation for a video game. Typically, graphics hardware includes a graphics pipeline configured to render frames by performing object, geometry, vertex, and raster operations on a set of graphics primitives designated for each frame. The graphics pipeline is often highly configurable. For example, the graphics pipeline may be configured with different shader programs, lighting constants, and texture maps, among other things. Typically, a graphics application invokes calls provided by the graphics API in order to render elements of a 3D scene, the most common being a “draw” call passed the coordinates of a polygon (e.g., a triangle) to be rendered. Widely used graphics APIs include the OpenGL® API distributed by the Khronos group and the Direct3D® API distributed by Microsoft®. A hardware driver provides an interface between the graphics API and a particular set of graphics hardware.
A typical cycle for debugging the graphics application includes compiling and running the application. As the application is running, the developer looks for any anomalies or visual artifacts in frames rendered by the hardware and software. Visual artifacts may include elements of a frame that have an appearance other than what was intended by the developer, and non-visual anomalies includes poor performance of the graphics application, such as a low rendering frame rate. These issues may occur due to the application setting an incorrect render state, using a non-optimal or incorrect texture, or the use of incorrect parameters supplied to draw calls, among other things.
Application developers commonly perform simple experiments to diagnose and resolve these types of visual artifacts and performance issues. For example, the developer may experiment with the graphics application by tweaking program source code, adjusting a render state, or changing parameters of the graphics pipeline. The developer then runs the application to observe the result. Although this approach can be effective, it often becomes a cumbersome process. Further, when trying to diagnose and correct a problem on a certain target platforms such as an embedded or hand-held device (e.g., a hand-held video game console, a mobile phone, PDA, or convergence device), the debugging process may be even more complicated as the graphics application must be deployed to the target device.
To address the inefficiency resulting from a purely ad-hoc approach, graphical application debuggers are available. However, these applications typically execute on the same system as the graphics application. For some devices, this approach is, at best, impractical due to the screen size of these devices. For example, most of the handheld video game devices currently available include screen resolutions of 320×240 or 640×480 pixels. Thus, the display screens may be too small to provide developers with a useful debugging interface. Further, the hand-held device may not have the processing power (or multi-tasking capability) required to run a graphical application debugger alongside a graphical application.
One approach to debugging an application for an embedded or handheld device is to debug the application remotely, for example, from a desktop personal computer. In such a case, a debugging tool should allow the developer to view the contents of the framebuffer on the remote device to help identify rendering bugs. For example, a debugging tool may be configured to capture the contents of a framebuffer on the remote device after a frame is rendered and transmit this information to the debugging tool running on a connected computer. However, this approach often requires significant bandwidth and, thus, often reduces the interactivity of the debugging tool. For example, for a remote device with a 640×480 display, a bitmap image for a single frame includes data for 307,200 pixels. With frame rates for a hand-held video game device often reaching 18-24 frames per-second, or more, waiting for large amounts of framebuffer data to be transmitted for each frame may substantially diminish the usefulness of the debugging tool.
An alternative approach is described in a related patent application titled “Serialization of Function Calls to a Graphics API for Debugging a Remote Device,” filed on DATE. This related application discloses a method in which a desktop PC may be configured to “play back” a sequence of serialized API calls for a given frame in order to recreate the contents of the remove device's framebuffer on the connected system. While this approach works well, problems arise when the graphics pipeline on the remote device includes programmable shading units. In such a case, the graphics application running on the remote device may include binary shader programs submitted to the graphics pipeline. Because the binary shader programs are pre-complied for the particular graphics hardware on the remote device, they cannot be replayed on the host system like the graphics API calls.
As the foregoing illustrates, there remains a need in the art for techniques to debug a graphics application running on a remote device, particularly where the graphics application includes shader programs compiled for the graphics hardware of the remote device.